For some IP applications such as IPTV it is often considered beneficial to introduce some guarantee on bandwidth availability, normally through the use of some form of bandwidth reservation. These schemes offer some advantages, but they are often expensive to deploy, and require a special technical and commercial relationship between the content and network providers. Usually, this means that to be a provider of IPTV it also necessary to be an ISP. In addition, the required admission control imposes a hard limit on the number of simultaneous streams which can lead to session refusals.
The encoding of video ideally requires a bit stream that varies in bandwidth. This enables complex portions of video (e.g. high spatial detail, high movement) to be encoded with more bits than simpler portions (e.g. talking head). Video encoded in this way is perceived as constant quality, but it requires a variable bit rate (VBR) transport. Most IPTV systems in place today (e.g. BT Vision) rely on the reservation of fixed portions of network bandwidth and use constant bit rate CBR video to match the reserved portion of bandwidth. Whilst simple to understand and to dimension such a system, it does not deliver a constant quality experience and importantly does not make the most effective use of the total available bandwidth.
It has been demonstrated by using constant quality video encoding (with a VBR) it is possible to double the number of simultaneous streams over the same network compared with using CBR encoding with the same perceived quality. However, there has been little work in exploring what mechanisms could actually be used to apportion the bandwidth in a channel to allow each stream in the channel to have constant quality video encoding.
Indeed, in applications that run over the Internet, the mechanisms in place in the IP protocol, and more specifically TCP/IP, tend to result in streams receiving the same bandwidth allocation. As already stated, this is not desirable, and instead it is preferred that each stream can be adapted to receive a bandwidth share that is proportional to the requirement relative to other streams in order to maintain a constant quality video stream.
In TCP/IP, the existing congestion avoidance techniques (such as those based on congestion window management) respond to network congestion by reducing the transmission rate. All TCP flows across the same portion of a congested network will respond in a similar fashion resulting in each flow getting a roughly equal share of the available bandwidth.
Explicit Congestion Notification (ECN) is protocol for signalling impending congestion in IP networks by marking packets rather than dropping them. Used with TCP it enables a sender to be informed of congestion so that it can reduce its transmission rate in an attempt to avoid impending congestion. As packets are not dropped, there is no need for packet re-transmission and network utility is improved. ECN uses 2 bits in the IP header, and in the case of ECN capable TCP a further 2 bits in the TCP header of a data packet to be transmitted.
A router equipped with active queue management, such as Random Early Detection (RED), marks IP headers with appropriate flags to signal congestion to the endpoints prior to the router's buffer overflowing and thus consequential packet loss. Under ideal conditions, there is little need for retransmissions, which gives rise to an improved overall throughput.
The IP header markings are detected at the receiver and are propagated up the stack to the transport protocol layer. In the case of TCP, further packet markings in the TCP header enable the receiver to signal to the sender that the network is becoming congested and that the sender should reduce the congestion window pre-emptively as if a packet loss had occurred.
FIG. 1 shows the IPv4 Type Of Service (TOS) octet 100, where bits 6 and 7 are designated as the ECN field 104. Specifically, the first 6 bits represent the differentiated services codepoint (DSCP) field 102, and the 2 following bits the ECN field 104, which can be set as follows:                0 0=Not ECN        0 1=ECN Capable Transport, ECT(1)        1 0=ECN Capable Transport, ECT(0)        1 1=CE Congestion Experienced        
FIG. 2 shows bytes 13 and 14 of a TCP header 200. Field 206 is for the congestion window reduced (CWR) flag and field 208 is for the ECN echo flag (ECE). The ECE flag is set by a receiver to signal to a sender that it has observed congestion (i.e. it has seen a CE flag in a received packet), while the CWR flag allows a sender to signal to a receiver that it has responded to congestion by reducing its congestion window. Typically these flags are set to “1” for flag active, and “0” for flag inactive.
In operation, each data packet is transmitted by a sender to a receiver with the ECN field 104 in the IP header set with codepoints “0 1” or “1 0” to signal ECN capable transport (i.e. the end points in this connection support ECN). If an intermediate router through which the data packets are routed is not experiencing congestion, then the data packets are simply forwarded to the receiver. The receiver responds by sending an acknowledgement packet ACK, with the ECT codepoints also set in the ACK data packet. The ACK data packet is received by the router and forwarded onto the sender.
Under ECN, if the router starts experiencing congestion, for example when the router's buffer is filled beyond a particular threshold, then the router will start marking data packets received from the sender with the congestion experienced flag in the ECN field of the IP header (codepoint=1 1) before forwarding onto the receiver. The receiver acknowledges successful receipt of the data packet by sending an acknowledgement packet ACK, with the ECT codepoint set in the IP header, as well as ECE flag in the TCP header. The ECE (ECN-Echo) flag is used to notify the sender that a router via which a previous packet was sent is experiencing congestion and had signalled as such using ECN. The ACK packet is received by the router and forwarded onto the sender. The receiver will continue marking all subsequent ACK packets with ECE set as a protection against dropped ACK packets until a suitable notification is received from the sender.
When the sender receives the ACK packet with ECE set, it knows that congestion was experienced on the network and behaves as if a packet had been dropped, which in the case of TCP is by halving the size of the congestion window. Depending on the variant of TCP being used, the size of the reduction can vary (a reduction of a half is common). The congestion window is defined as the number of segments that the sender can send before receiving an ACK. In effect, the larger the congestion window, the larger the number of data packets that can be outstanding at a given time. Conversely, a reduction in the size of the congestion window will reduce the number of data packets that can be outstanding and thus effectively reduce the number of data packets sent in a given time frame i.e. the transmission rate.
The sender thus acknowledges receipt of the ACK packet by marking the next data packet it sends with the ECT and congestion window reduced CWR 206 flags set. This ECT and CWR marked data packet is transmitted by the sender, and forwarded to the receiver. Once the receiver has received this data packet with CWR set, the receiving terminal stops marking ACK packets with the ECE flag. A data packet with the CE flag set that is received after a received data packet with CWR set is treated as a new instance of congestion.
Thus, it can be seen that by using the ECN enabled TCP protocol, it is possible for a router to notify the sender of congestion before packets need to be dropped, with the sender reacting by reducing the size of the congestion window. However, the problem of how to intelligently allocate bandwidth share across multiple data flows still arises, as all the flows (across the same portion of a congested network) will respond in a similar fashion even under ECN and thus each flow will still get a roughly equal share of the available bandwidth.